Loadstar 24/024.d81/t.garbage collec

Text File | 1986-01-01 | 5.7 KB | 359 lines

  GARBAGE COLLECTING EXPLAINED--

           ONE SOLUTION
                by
            Dick Bull


  When writing and running file

programs in BASIC, I would run into

an apparent lockup in my 64.  I had

read some articles on garbage

collection.  Could this be my

problem??  After rereading the

articles I was convinced that this

was indeed what was happening and

went along with the authors' opinion

that nothing could be done about it.

When working on my last program,

however, it became a major problem,

so I went back to the research.


  Microsoft BASIC used by Commodore

does not set aside a specific

location to store its strings in.

Instead it utilizes any unused memory

available, starting at the highest

address used by BASIC, 40959, and

works down until it's about to

collide with the BASIC arrays. BASIC

arrays store themselves working

upwards. You can't possibly use up

the 30k remaining after your program,

can you?.. Yes!!! Here comes the

garbage.  A simple program can use up

a lot of "string memory":

10 B$="bill": print "[clr]"
20 input "Your name";A$
30 print "Hi "A$
35 if A$=B$ then 60
40 print "sorry I am not looking for
you today"
50 for t= 1 to 2000: next: goto 10
60 print "lets get to work"
70 rem rest of program


  Each time a new name is entered it

uses up memory, not permanently like

a program or the strings you want to

keep, but temporarily until the

computer needs the room. Suppose I

were to enter "Fred" to the prompt in

line 20. The computer would store it

like this:


     40949 = d
     40958 = e
     40957 = r
     40956 = F


  The computer then sets the pointer

for a$ (elsewhere in memory) to point

to 40956. "Fred" is not what the

program was looking for so the

program goes back to 10.  Next I enter

"Tom"; the computer continues to store

in a downward direction and changes

the pointer for a$ to start at 40953.


     40955 = m
     40954 = o
     40953 = T


"Fred" 40956 - 40959 becomes useless

garbage. The computer is content to

waste this space until it is needed.

When the 64 goes to store a string

and can't find enough room, it takes

out the garbage, crunching any

strings that are still needed toward

the top of memory.


  This garbage collection routine can

take considerable time and your

computer will appear to lock up.

I don't know the maximum time it can

take, but I know I have hit the

run/stop key and finally the

[run/stop restore] out of desperation

thinking the computer had gone to

never never land. It will take about

nineteen minutes for 3800 strings to

be garbage collected.


WHAT AFFECTS THE TIME IT TAKES?


  There are two variables: how long

will the garbage collection take and

how often will it be needed. The

number of valid strings and the

number of string arrays declared in a

dim statement have the greatest effect

on the time needed to garbage

collect.  The amount of garbage

generated and the length of the

strings still needed does not have a

significant effect on the time

required.  They will ,however,

determine how often garbage

collection is needed.


  Doubling either the number of

strings used or the number

dimensioned doubles the time

required. A variable dimensioned to

200 and with 100 used will take about

1.5 seconds; dimed to 500 and 250

used takes 8.4 seconds; 3200

dimensioned and used will take 13

minutes and 29 seconds to crunch the

strings and clear the garbage.


IS THERE A SOLUTION?


  You can force the computer to

garbage collect at a time convenient

to you by using the fre(0) command.

This is what I tried first, forcing a

collection when returning to the main

menu. It soon became a pain in the

neck to wait, even if the computer

had just done the job. I had read

that you could not predict when

collection was going to occur so this

was the best that I could manage.  I

could tell from the partially

finished menu screen that it was

garbage collecting and not locked up.


  Thinking of my predicament, I kept

coming back to the fact that if the

computer knew when it needed to

collect, why couldn't I know too?

Looking at a memory map I discovered

the solution.  Memory locations 51

and 52 contained the pointer to the

bottom of string storage.  Location

49 and 50 contained the pointer to

the top of basic arrays.  A one line

computation would tell me the amount

of unused memory available before

garbage collection was necessary:


300 f= peek(52)*256 + peek(51) -
    peek(50)*256 - peek(49)


Not needing an exact figure I was

able to shorten the test and write

the following routine that prints a

prompt and forces collection if it

would be needed soon:


300 IF PEEK(52)-PEEK(51)>1 THEN
    RETURN

310 PRINT"[home][red]TAKING OUT THE
GARBAGE-BACK IN A MOMENT[cyn]"

320 FR=FRE(0):PRINT"[csr up][39
spaces]":POKE 198,0 : RETURN


  It is then only necessary to place

a gosub 300 after each string

manipulation.  Line 300 checks for

at least 256 free bytes left.  If so,

it returns to your program.  If the 1

in >1 is increased the routine can be

called less often. The max input#

length is 80 charactors, so with >1

it could be called every three

inputs, 3 * 80 = 240.


  If it is time to collect garbage

the prompt in 310 is printed,

collecting is accomplished, and

the prompt is erased by line 320. By

poking 198 with 0 it clears the

keyboard buffer in case someone has

been impatiently pressing keys. The

prompt gives the indication of what

is currently going on within the

apparently locked-up computer. The

colors and the positioning used can

of course be altered to fit the

program.


  It is reassuring to see the prompt

come on and then clear before

execution is resumed. I also added

sound routines at the start and end

to alert me to the change in program

status.

-----------<end of text>-------------